Research Student Monitoring Group Report 4 , academic year 2007 / 2008

Automatic Programming (AP) [15] is an ambitious goal that has been greedily sought since the 1950s. During the history of computer science, the term AP has been used for different concepts. Here, with the term AP we define the automation of implementing software given a starting formal specification. In the past, the work about AP was based on transformations (e.g., [11]), in which formal rules were used to map high level specification expressions to low level implementations. Such an approach has many limits, because not always there can be this direct mapping. For example, in that way we cannot automatically implement even a simple sorting algorithm whose specification just states that each element should be lower or equal than the next one, and that the final array should be a permutation of the input one. To our best knowledge, no general approach that might be able to tackle each possible specification has been proposed yet. Hence, we proposed a novel evolutionary approach [5] based on Co-evolution, Genetic Programming (GP) [12] and Search Based Software Testing [14]. The main difference from standard applications of GP is that we use the formal specification for automatically generating the fitness function that will guide the evolution. Moreover, there is the problem of generating a proper training set, that will be composed by Unit Tests. We do that with a co-evolution. In other words, we use search based software testing techniques to evolve unit tests to discover new bugs (if any) in the current generation of genetic programs. Hence, at each generation, we evolve the programs to pass the unit tests, and at the same time we evolve the unit tests for finding new bugs in the programs. Hopefully, this co-evolution will lead to an arms race that will bring to the evolution of a program that satisfies the given formal specification. Although we got some preliminary results [5], those results show some performance limitations. The main problems are that GP is still an immature field, and moreover we are not sure whether it is possible to generate good fitness functions (i.e., functions that do not show a “needle in the hay-stack” behaviour) for most software specifications. However, the approach that we proposed might work for any feasible software, and that is the only approach we know that might do it. Instead of trying to improve our AP framework for evolving program from scratch, we think it is more wise to use it to tackle a related simpler problem: Automatic Bug Fixing (ABF), which consists of fixing bugs in software in an automatic way. The idea is very simple: given a bugged program and a formal specification of it, we use the above framework to evolve a correct program. The main difference is that, instead of starting the co-evolution with a random population of genetic programs, we seed the first genetic population with n copies of the bugged program. Because in general we start with a solution that is structurally near to the optimal one, we might expect to fix bugs even in complex software. For the same reason, we can use ABF even when only a fixed set of unit tests (i.e., a test suite) is provided (i.e., no formal specification), because sub-optimal solutions are less likely to happen than in AP (more details can be found in [4, 3]). At any rate, showing the feasibility of our AP framework is still important, because in this way we can infer that ABF might potentially handle any type of bug. In literature, there is a huge amount of work on Software Testing. However, software testing can only show the presence of bugs. Although there have been (comparatively few) work on how to localise the position of the bugs (i.e., Automating Debugging, e.g. [17]), to our best knowledge the actual change of the code to fix the